home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group95c.txt / 000106_icon-group-sender _Fri Dec 1 09:54:05 1995.msg < prev    next >
Internet Message Format  |  1996-01-03  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Fri, 1 Dec 1995 07:19:36 MST
  2. Date: Fri, 1 Dec 1995 09:54:05 +0200 (WET)
  3. From: Ehud Lamm <mslamm@pluto.mscc.huji.ac.il>
  4. To: gep2@computek.net
  5. Cc: icon-group@cs.arizona.edu
  6. Subject: Re: "Simplification" of Icon
  7. In-Reply-To: <9511301400.AA21916@ns1.computek.net>
  8. Message-Id: <Pine.A32.3.91.951201094455.37593C-100000@pluto.mscc.huji.ac.il>
  9. Mime-Version: 1.0
  10. Content-Type: TEXT/PLAIN; charset=US-ASCII
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13.  
  14.  
  15.  
  16. On Thu, 30 Nov 1995 gep2@computek.net wrote:
  17.  
  18. > >I'd personally love to see a language like Icon that did away with auto-
  19. > matic type conversions (I rarely used them anyway), 
  20. > 
  21. > Are You Kidding!!!???  That is one of the things that is the MOST BASIC about 
  22. > the appeal of something like ICON (or SNOBOL4, for that matter)... that if 
  23. > something is numeric, you can treat it like a number... without having to do 
  24. > manual conversions on it!  And that likewise, you can treat numbers like strings 
  25. > when it's appropriate and desirable to do so!
  26.  
  27. I think the Icon group survived quite well without flaming. I think we 
  28. can continue with this tradition. Ad-hominem remarks are really 
  29. disgusting (don't YOU think) :-)
  30.  
  31. Anyway the issue raised is an important one. 
  32.  
  33. Automatic conversion can be terrible (see PL/1 for an example), when they 
  34. don't work as expected - and I have seen many such cases in other 
  35. languages. 
  36. On the other hand hidden type information and conversions are also basic 
  37. tools used in many VHLL (very high level languages) such as Rexx, SNOBOL, 
  38. Icon etc. 
  39. The problem is to find the right combination of ease of use ("123"+4) and 
  40. type safety ("0.1" + 1 is an integer, a float or maybe it doesn't matter 
  41. which??).
  42.  
  43. I think Icon is pretty good in this respect, though I must add I didn't 
  44. really try to break its type system recently. 
  45.  
  46. We have to remember the VHLL raise many issues not found in normal HLL 
  47. design. A VHLL must allow you to rapidlly code and debug, without having 
  48. to deal with to many technical obstacles. This also means that it is not 
  49. always such a great idea to say "you can just link to C" since this adds 
  50. to the work of the programmer.
  51.  
  52. On the other hand VHLLs like all languages should be orthogonal and clean 
  53. - and not suffer from to many diconected features. But again, I think 
  54. this hardly characterizes Icon.
  55.  
  56. Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
  57.  
  58.